ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/tsql/doc/tsql.mail/[e-mail]…s64.cineca.it _Thu May 13 12:48:35 1993.msg

Internet Message Format | 1996-01-31 | 4KB

Received: from icineca.cineca.it by optima.CS.Arizona.EDU (5.65c/15) via SMTP
    id AA29186; Thu, 13 May 1993 03:46:43 MST
Received: from deis64.cineca.it by ICINECA.CINECA.IT (IBM VM SMTP V2R2)
   with TCP; Thu, 13 May 93 12:47:00 SET
Received: from [137.204.57.79] (deis79) by deis64.cineca.it (4.1/SMI-4.1)
    id AA24060; Thu, 13 May 93 12:48:49 +0200
Date: Thu, 13 May 93 12:48:35 +0100
From: (Fabio Grandi) <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Benchmark Query Taxonomy.

This message is addressed to C.Jensen, as author of the query taxonomy,
but it may of interest for all the benchmark authors.
It concerns the classification of queries retrieving user-defined time.
Obviously, any comment on the topic is welcome.

Best regards,
        Fabio Grandi.

----------------------------------------------------------------------------

Dear Christian,

I find it difficult to classify a query only retrieving user-defined times
according to your taxonomy, e.g.: "Find the date of birth of *ED*".

With reference to the last benchmark draft,
should the output of such queries be classified
    as:     (a) - (Projected, None)
 or as:     (b) - (None, (*, "value") )   ?

I don't feel that Solution (a) is a most happy one,
since the query retrieves something that has the meaning for the user
of a valid-time, even more than a (*, (*, Imposed) ) query.

If the solution (b) is chosen, which is the category for "value" ?
It doesn't seem to be "Derived" (b.1), since it is not "computed solely
in terms of the valid-time components of the tuples in the argument
relation".
It doesn't seem either to be "Imposed" (b.2), since it is not "computed
by explicit assignment in the query".

Should we slightly modify the definitions of Derived/Imposed to
capture the query into (b.1) or (b.2), or should we introduce
a third category (b.3) (e.g. User-defined or something like that)
for the "value" category of the "valid-time component" category
in the output taxonomy?
I think that the introduction of a (b.3) category would also be consistent
with the same distinction effected in defining the "origin of arg_2"
category in the Valid-time Selection-based Taxonomy.

However, the definition of a (b.3) category would not solve
every problem. What for queries retrieving both valid-time
(derived or imposed) and user-defined time(s)? Should we otherwise
introduce a third category (c) in the main Output-based Taxonomy?
This would become:
  { explicit-attribute component }
  x { valid-time component } x { user-defined-time component(s) }
I find it ugly.

Moreover, since also data constants could be "imposed" in queries
as output values for explicit-attributes (e.g. you can do it in SQL),
an alternative third category (c') could be introduced in the main
Output-based Taxonomy to include "imposed" values (explicit-attribute
and/or valid-time), once Imposed has been canceled from the "value"
category of the "valid-time component".

Although this could be - in my opinion - an acceptable solution,
it would require a major revision of the class definitions
we already started to use. The previous solution has the same drawback.

Finally, my proposal is the following:
 1. definitely classify queries retrieving user-defined times as (a);
 2. forget about "imposed" values (valid-time, any time, explicit attributes)
    at least in this first benchmark phase;
 3. avoid the distinction between "user-defined attribute value"
    and "computed from other valid times" in the "origin of arg_2" category
    of the Valid-time Selection-based Taxonomy. They can be merged into:
    Computed - "computed from other times" (stored in the argument tuples).

If 3. is not enforced, the classification problem conceptually arises again,
if you consider "arg_2" as retrieved by an ideal subquery.
Otherwise, what is the purpose of the distinction?

----------------------------------------------------------------------------